fix(web): pin image annotations to the picture, not the letterboxed box - #236

Drawings on images were authored and replayed against the full container
box rather than the picture inside it. `use-drawing` sized the Fabric
canvas from the parent container, stored that size as
`_canvasWidth`/`_canvasHeight`, and `AnnotationOverlay` rescaled by a
plain per-axis ratio on display. That rescale is only correct when the
display container has the same aspect ratio as the authoring one, so any
change of shape (sidebar collapsed vs expanded, a resized window, a
compare pane, a share link) both stretched the drawing and moved the
picture underneath it.

Measured in a browser: a 3:1 image annotated at 25% down the picture in
a 900x500 viewer, reopened at 400x700, put the mark at -29% — 54% of the
image height adrift and off the picture entirely. Through the new
constraint it lands at 25% exactly.

Video never had this bug; `VideoFrameConstraint` already fits the overlay
to the rendered video box. This is the image counterpart, but it cannot
be a copy. `<video>` is `w-full h-full object-contain`, so it fills its
container and the contain fit can be derived from the container. Images
are `max-w-full max-h-full`, and `max-*` only ever shrinks, so an image
smaller than its container renders at natural size rather than scaling
up. Deriving the box from the container upscales it in that case —
verified: a 100x200 image in an 800x400 box really occupies 100x200 at
(350,100), where container-derived math claims 200x400 at (300,0).

`renderedImageBox` therefore runs the contain fit inside the element's
own box and offsets by where that element sits, which is correct for
both patterns. It reads offset* rather than a client rect because this
renders inside react-zoom-pan-pinch's transform, where a client rect
would fold in the zoom matrix.

Applied to all four surfaces that show image annotations: the single
viewer (which also covers the folder share viewer, since that routes
through ImageViewer), both side-by-side compare panes, and the wipe
view. Wipe is not optional — once authoring moves to image space, a
viewer left in container space becomes newly wrong rather than merely
inconsistent.

`AnnotationOverlay` and `AnnotationCanvas` are unchanged: both size
themselves from their parent, so mounting them inside the constraint is
the whole mechanism.

Note for existing data: image annotations saved before this change were
only ever correct in the exact container they were drawn in, and are now
interpreted in image space, so they will shift.

Closes #185

The first pass at legacy compatibility replayed old annotations against the
container they were authored in, reproducing their original placement
exactly. That was faithful but not useful: those coordinates were always
container-relative, so the mark still slid around as the viewer's aspect
ratio changed. Manual testing showed exactly that, a mark drifting off the
detail it was drawn on.

The stored dimensions plus the image's intrinsic size are enough to do
better. The picture box inside the authoring container is just the contain
fit of the natural size into the stored `_canvasWidth`/`_canvasHeight`, so an
old mark can be re-expressed relative to the picture and replayed at any
size. Two marks on a 1200x800 image saved in a 520x870 pane sit 32.0% and
30.8% down the picture; they now render at that same point whether the pane
is 1400x900, 900x500 or 600x1000, where before each pane put them somewhere
different.

This does move existing annotations relative to where they rendered before,
which the CHANGELOG now says plainly. The new position is the one they were
drawn at.

The context carries the intrinsic size rather than the container box, since
that is all the reconstruction needs, and it is null on surfaces that always
authored in media space so video data is left alone.